Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Allow Standalone nodes to operate in an orchestrated environment #138

Open
wants to merge 8 commits into
base: master
Choose a base branch
from
Open

Allow Standalone nodes to operate in an orchestrated environment #138

wants to merge 8 commits into from
+76 −31

Conversation

clone1018
Copy link
Member

@clone1018 clone1018 commented Jun 21, 2022 •
edited
Loading

Essentially what this allows for is a node to act within an orchestrator network as both an ingest & edge. Serving up video directly from itself, and proxying it from other nodes as required. Working on one server as a proof of concept, but would appreciate a logic review!

Currently a test server is available at: do-nyc3-combo1.kjfk.live.glimesh.tv. You can easily stream to it and watch on Glimesh.tv and test edge functionality by using https://glimesh.github.io/janus-ftl-player/ and your favorite channel_id.

Checklist

  • Watching combo1 stream from edge1 while configured as standalone
  • Watching combo1 stream from combo1 while configured as standalone
  • Watching ingest1 stream from combo1 while configured as standalone
  • Traditional ingest functionality with orchestrator
  • Traditional edge functionality with orchestrator
  • Traditional standalone functionality without orchestrator

@clone1018 clone1018 marked this pull request as draft June 21, 2022 12:47
@clone1018
Copy link
Member Author

Slight error on watching ingest1 stream from combo1:

janus[66953]: [2022-06-21 12:47:23.805] [info] New request watch
janus[66953]: [2022-06-21 12:47:23.805] [info] Request to watch channel 16791
janus[66953]: terminate called after throwing an instance of 'std::runtime_error'
janus[66953]:   what():  Unexpected service connection type - expected EdgeNodeServiceConnection.

@clone1018
Copy link
Member Author

Seems to be fully functional now, but would appreciate feedback on a better way of handling the switch between interacting with the EdgeNodeServiceConnection (if using a relayed stream) vs XServiceConnection (if streaming directly to the Standalone node).

https://github.com/Glimesh/janus-ftl-plugin/pull/138/files#diff-d010314ca062375c6ab0cd796195ecdcd29f61cee79ed68a69d1b3dc53b74497R340-R347

@clone1018 clone1018 changed the title Combination Node Kind Allow Standalone nodes to operate in an orchestrated environment Jun 26, 2022
@clone1018 clone1018 requested review from haydenmc and danstiner June 26, 2022 19:49
@clone1018 clone1018 marked this pull request as ready for review June 26, 2022 19:58
haydenmc
haydenmc reviewed Jun 26, 2022
View reviewed changes
src/JanusFtl.cpp
@@ -749,17 +770,20 @@ janus_plugin_result* JanusFtl::handleWatchMessage(ActiveSession& session, JsonPt

// If we're an Edge node and this is a first viewer for a given channel,
// request that this channel be relayed to us.
if ((configuration->GetNodeKind() == NodeKind::Edge) && (pendingViewers == 0))
if (orchestrationEnabled && (pendingViewers == 0))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking through a potential ambiguity in this codepath -

Consider a scenario where a standalone FTL instance receives a watch request for a channel that has not started streaming yet. The standalone FTL server will subscribe to the channel via orchestrator.

Afterwards, the streamer actually begins streaming, but connects to the same standalone FTL server.

I suspect the orchestrator will fulfill the standalone FTL server's subscription and notify the server to relay the stream to itself.

Since only one stream can exist per channel, the standalone server will probably terminate the stream (or maybe worse, haven't really traced it through all the way).

We'll probably need special behavior to either

1.) Enlighten the orchestrator so it can handle when a standalone server tries to publish a stream on the same channel that it previously has subscribed to

2.) Enlighten the standalone FTL server so it can handle "transitioning" between a pending orchestrator relay and a "direct" stream

Thoughts?

haydenmc
haydenmc reviewed Jun 26, 2022
View reviewed changes
src/JanusFtl.cpp Outdated Show resolved Hide resolved
src/JanusFtl.cpp Outdated Show resolved Hide resolved
src/JanusFtl.cpp Outdated Show resolved Hide resolved
@clone1018
Copy link
Member Author

Getting back to this now, if I remember correctly there's a single remaining bug:

Viewer opens stream, combo server adds them to the pendingViewerSessions, then a new stream connects.... How do I differentiate between a new stream from an ingest, and a new stream from a user directly.

Will need to think on this tomorrow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@haydenmc haydenmc haydenmc left review comments

@danstiner danstiner Awaiting requested review from danstiner

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@clone1018 @haydenmc